SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Pair programming</title>

</head>

Pair programming

</h1>

</header>

Pair programming is a <a href="Software_development" title="Software development">software development</a> technique in which two <a href="Computer_programmer" class="mw-redirect" title="Computer programmer">programmers</a> work together at one <a href="Workstation" title="Workstation">workstation</a>. One, the driver, writes <a href="Source_code" title="Source code">code</a> while the other, the observer or navigator,<a href="#cite_note-1">[1]</a> <a href="Code_review" title="Code review">reviews</a> each line of code as it is typed in. The two programmers switch roles frequently.

While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

<div class="mw-heading mw-heading2"><h2 id="Economics">Economics</h2></div>

Pair programming increases the <a href="Man-hour" title="Man-hour">man-hours</a> required to deliver code compared to programmers working individually.<a href="#cite_note-ijhcs-2">[2]</a> However, the resulting code has fewer defects.<a href="#cite_note-costs-benefits-3">[3]</a> Along with code development time, other factors like field support costs and quality assurance also figure into the return on investment. Pair programming might theoretically offset these expenses by reducing defects in the programs.<a href="#cite_note-costs-benefits-3">[3]</a>

In addition to preventing mistakes as they are made, other intangible benefits may exist. For example, the courtesy of rejecting phone calls or other distractions while working together, taking fewer breaks at agreed-upon intervals or sharing breaks to return phone calls (but returning to work quickly since someone is waiting). One member of the team might have more focus and help drive or awaken the other if they lose focus, and that role might periodically change. One member might know about a topic or technique that the other does not, which might eliminate delays to finding or testing a solution, or allow for a better solution, thus effectively expanding the skill set, knowledge, and experience of a programmer as compared to working alone. Each of these intangible benefits, and many more, may be challenging to accurately measure but can contribute to more efficient working hours.

<div class="mw-heading mw-heading2"><h2 id="Design_quality">Design quality</h2></div>

A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons:

<ol><li>the programmers bring different prior experiences to the task;</li>

<li>they may assess information relevant to the task in different ways;</li>

<li>they stand in different relationships to the problem by their functional roles.</li></ol>

In an attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.<a href="#cite_note-4">[4]</a>

<div class="mw-heading mw-heading2"><h2 id="Satisfaction">Satisfaction</h2></div>

In an online survey of pair programmers from 2000, 96% of programmers stated that they enjoyed working more while pair programming than programming alone. Furthermore, 95% said that they were more confident in their work when they pair programmed. However, as the survey was among self-selected pair programmers, it did not account for programmers who were forced to pair program.<a href="#cite_note-strengthening-5">[5]</a>

<div class="mw-heading mw-heading2"><h2 id="Learning">Learning</h2></div>

Knowledge is constantly shared between pair programmers, whether in the industry or in a classroom. Many sources suggest that students show higher confidence when programming in pairs,<a href="#cite_note-strengthening-5">[5]</a> and many learn whether it be from tips on <a href="Programming_language" title="Programming language">programming language</a> rules to overall design skills.<a href="#cite_note-support-6">[6]</a> In "promiscuous pairing", each programmer communicates and works with all the other programmers on the team rather than pairing only with one partner, which causes knowledge of the system to spread throughout the whole team.<a href="#cite_note-costs-benefits-3">[3]</a> Pair programming allows programmers to examine their partner's code and provide feedback, which is necessary to increase their own ability to develop monitoring mechanisms for their own learning activities.<a href="#cite_note-support-6">[6]</a>

<div class="mw-heading mw-heading2"><h2 id="Team-building_and_communication">Team-building and communication</h2></div>

Pair programming allows team members to share quickly, making them less likely to have agendas hidden from each other. This helps pair programmers learn to communicate more easily. "This raises the communication bandwidth and frequency within the project, increasing overall information flow within the team."<a href="#cite_note-costs-benefits-3">[3]</a>

<div class="mw-heading mw-heading2"><h2 id="Studies">Studies</h2></div>

There are both empirical studies and meta-analyses of pair programming. The empirical studies tend to examine the level of productivity and the quality of the code, while meta-analyses may focus on biases introduced by the process of testing and publishing.

A <a href="Meta-analysis" title="Meta-analysis">meta-analysis</a> found pairs typically consider more design alternatives than programmers working alone, arrive at simpler, more maintainable designs, and catch design defects earlier. However, it raised concerns that its findings may have been influenced by "signs of <a href="Publication_bias" title="Publication bias">publication bias</a> among published studies on pair programming." It concluded that "pair programming is not uniformly beneficial or effective."<a href="#cite_note-hannay-meta-7">[7]</a>

Although pair programmers may complete a task faster than a solo programmer, the total number of <a href="Man-hour" title="Man-hour">man-hours</a> increases.<a href="#cite_note-ijhcs-2">[2]</a> A manager would have to balance faster completion of the work and reduced testing and <a href="Debugging" title="Debugging">debugging</a> time against the higher cost of coding. The relative weight of these factors can vary by project and task.

The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication, and for novices as compared to experts.<a href="#cite_note-ijhcs-2">[2]</a> Pair programming could be helpful for attaining high quality and correctness on complex programming tasks, but it would also increase the development effort (cost) significantly.<a href="#cite_note-hannay-meta-7">[7]</a>

On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity.<a href="#cite_note-ijhcs-2">[2]</a><a href="#cite_note-Arisholm_2007_65–86-8">[8]</a> It may reduce the code development time but also risks reducing the quality of the program.<a href="#cite_note-hannay-meta-7">[7]</a> Productivity can also drop when novice–novice pairing is used without sufficient availability of a mentor to coach them.<a href="#cite_note-9">[9]</a>

A study of programmers using AI assistance tools such as <a href="GitHub_Copilot" title="GitHub Copilot">GitHub Copilot</a> found that while some programmers conceived of AI assistance as similar to pair programming, in practice the use of such tools is very different in terms of the programmer experience, with the human programmer having to transition repeatedly between driver and navigator roles.<a href="#cite_note-10">[10]</a>

<div class="mw-heading mw-heading2"><h2 id="Indicators_of_non-performance">Indicators of non-performance</h2></div>

There are indicators that a pair is not performing well:

<ul><li>Disengagement may present as one of the members physically withdraws away from the keyboard, accesses email, or even falls asleep.</li>

<li>The "Watch the Master" phenomenon can arise if one member is more experienced than the other. In this situation, the junior member may take the observer role, deferring to the senior member of the pair for the majority of coding activity. This can easily lead to disengagement.</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Pairing_variations">Pairing variations</h2></div>

<dl><dt>Expert–expert</dt>

<dd>Expert–expert pairing may seem to be the obvious choice for the highest productivity and can produce great results, but it often yields little insight into new ways to solve problems, as both parties are unlikely to question established practices.<a href="#cite_note-ijhcs-2">[2]</a></dd>

<dt>Expert–novice</dt>

<dd>Expert–novice pairing creates many opportunities for the expert to mentor the novice. This pairing can also introduce new ideas, as the novice is more likely to question established practices. The expert, now required to explain established practices, is also more likely to question them. However, in this pairing, an intimidated novice may passively "watch the master" and hesitate to participate meaningfully. Also, some experts may not have the patience needed to allow constructive novice participation.<a href="#cite_note-11">[11]</a></dd>

<dt>Novice–novice</dt>

<dd>Novice–novice pairing can produce results significantly better than two novices working independently, although this practice is generally discouraged because it is harder for novices to develop good habits without a proper role model.<a href="#cite_note-costs-benefits-3">[3]</a></dd></dl>

<div class="mw-heading mw-heading2"><h2 id="Remote_pair_programming">Remote pair programming</h2></div>

Remote pair programming, also known as virtual pair programming or distributed pair programming, is pair programming in which the two programmers are in different locations,<a href="#cite_note-12">[12]</a> working via a <a href="Collaborative_real-time_editor" title="Collaborative real-time editor">collaborative real-time editor</a>, shared desktop, or a remote pair programming <a href="Integrated_development_environment" title="Integrated development environment">IDE</a> plugin. Remote pairing introduces difficulties not present in face-to-face pairing, such as extra delays for coordination, depending more on "heavyweight" task-tracking tools instead of "lightweight" ones like index cards, and loss of verbal communication resulting in confusion and conflicts over such things as who "has the keyboard".<a href="#cite_note-jucs-13">[13]</a>

Tool support could be provided by:

<ul><li>Whole-screen sharing software<a href="#cite_note-14">[14]</a><a href="#cite_note-15">[15]</a></li>

<li><a href="Terminal_multiplexer" title="Terminal multiplexer">Terminal multiplexers</a></li>

<li>Specialized distributed editing tools</li>

<li>Audio chat programs or VoIP software could be helpful when the screen sharing software does not provide two-way audio capability. Use of headsets keep the programmers' hands free</li>

<li>Cloud development environments</li>

<li>Collaborative pair programming services</li></ul>

<ul><li><a href="Extreme_programming" title="Extreme programming">Extreme programming</a></li>

<li><a href="Joint_attention" title="Joint attention">Joint attention</a></li>

<li><a href="Team_programming" title="Team programming">Team programming</a> (also known as mob programming)</li>

<li><a href="Body_Doubling" class="mw-redirect" title="Body Doubling">Body Doubling</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist reflist-columns references-column-width" style="column-width: 30em;">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite id="CITEREFWilliams2001" class="citation conference cs1"><a href="Laurie_Williams_(software_engineer)" title="Laurie Williams (software engineer)">Williams, Laurie</a> (February 19–20, 2001). Integrating pair programming into a software development process. 14th Conference on Software Engineering Education and Training. Charlotte. pp. 27–36. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FCSEE.2001.913816">10.1109/CSEE.2001.913816</a>. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>0-7695-1059-0</bdi>. <q>One of the programmers, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects, and also thinks strategically about the direction of the work.</q></cite>

</li>

<li id="cite_note-ijhcs-2">^ <a href="#cite_ref-ijhcs_2-0">a</a> <a href="#cite_ref-ijhcs_2-1">b</a> <a href="#cite_ref-ijhcs_2-2">c</a> <a href="#cite_ref-ijhcs_2-3">d</a> <a href="#cite_ref-ijhcs_2-4">e</a> <cite id="CITEREFLui2006" class="citation journal cs1">Lui, Kim Man (September 2006). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20110720105133/http://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.pdf">"Pair programming productivity: Novice–novice vs. expert–expert"</a> (PDF). International Journal of Human–Computer Studies. 64 (9): 915–925. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.364.2159">10.1.1.364.2159</a>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2Fj.ijhcs.2006.04.010">10.1016/j.ijhcs.2006.04.010</a>. Archived from <a rel="nofollow" class="external text" href="http://www.cs.utexas.edu/users/mckinley/305j/pair-hcs-2006.pdf">the original</a> (PDF) on 2011-07-20. Retrieved 2012-11-18.</cite>

</li>

<li id="cite_note-costs-benefits-3">^ <a href="#cite_ref-costs-benefits_3-0">a</a> <a href="#cite_ref-costs-benefits_3-1">b</a> <a href="#cite_ref-costs-benefits_3-2">c</a> <a href="#cite_ref-costs-benefits_3-3">d</a> <a href="#cite_ref-costs-benefits_3-4">e</a> <cite id="CITEREFCockburnWilliams2000" class="citation journal cs1"><a href="Alistair_Cockburn" title="Alistair Cockburn">Cockburn, Alistair</a>; <a href="Laurie_Williams_(software_engineer)" title="Laurie Williams (software engineer)">Williams, Laurie</a> (2000). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20161217103943/http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF">"The Costs and Benefits of Pair Programming"</a> (PDF). Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000). Archived from <a rel="nofollow" class="external text" href="http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF">the original</a> (PDF) on 2016-12-17. Retrieved 2007-11-05.</cite>

</li>

<li id="cite_note-4"><a href="#cite_ref-4">^</a> <cite id="CITEREFFlorHutchins1991" class="citation book cs1">Flor, Nick V.; Hutchins, Edwin L. (1991). <a rel="nofollow" class="external text" href="https://books.google.com/books?id=KT_bpSSJBgcC&pg=PA36">"Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance"</a>. In Koenemann-Belliveau, Jürgen; Moher, Thomas G.; Robertson, Scott P. (eds.). Empirical Studies of Programmers: Fourth Workshop. Ablex. pp. 36–64. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-89391-856-9</bdi>.</cite>

</li>

<li id="cite_note-strengthening-5">^ <a href="#cite_ref-strengthening_5-0">a</a> <a href="#cite_ref-strengthening_5-1">b</a> <cite id="CITEREFWilliamsKesslerCunninghamJeffries2000" class="citation journal cs1"><a href="Laurie_Williams_(software_engineer)" title="Laurie Williams (software engineer)">Williams, Laurie</a>; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). <a rel="nofollow" class="external text" href="http://sunnyday.mit.edu/16.355/williams.pdf">"Strengthening the case for pair programming"</a> (PDF). IEEE Software. 17 (4): 19–25. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.5248">10.1.1.33.5248</a>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2F52.854064">10.1109/52.854064</a>.</cite>

</li>

<li id="cite_note-support-6">^ <a href="#cite_ref-support_6-0">a</a> <a href="#cite_ref-support_6-1">b</a> <cite id="CITEREFWilliamsUpchurch2001" class="citation journal cs1"><a href="Laurie_Williams_(software_engineer)" title="Laurie Williams (software engineer)">Williams, Laurie</a>; Upchurch, Richard L. (2001). <a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F366413.364614">"In support of student pair programming"</a>. ACM SIGCSE Bulletin. 33 (1): 327–31. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F366413.364614">10.1145/366413.364614</a>.</cite>

</li>

<li id="cite_note-hannay-meta-7">^ <a href="#cite_ref-hannay-meta_7-0">a</a> <a href="#cite_ref-hannay-meta_7-1">b</a> <a href="#cite_ref-hannay-meta_7-2">c</a> <cite id="CITEREFHannayTore_DybåErik_ArisholmDag_I.K._Sjøberg2009" class="citation journal cs1">Hannay, Jo E.; Tore Dybå; Erik Arisholm; Dag I.K. Sjøberg (July 2009). "The Effectiveness of Pair Programming: A Meta-Analysis". Information and Software Technology. 51 (7): 1110–1122. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1016%2Fj.infsof.2009.02.001">10.1016/j.infsof.2009.02.001</a>.</cite>

</li>

<li id="cite_note-Arisholm_2007_65–86-8"><a href="#cite_ref-Arisholm_2007_65–86_8-0">^</a> <cite id="CITEREFArisholmHans_GallisTore_DybåDag_I.K._Sjøberg2007" class="citation journal cs1">Arisholm, Erik; Hans Gallis; Tore Dybå; Dag I.K. Sjøberg (February 2007). <a rel="nofollow" class="external text" href="https://web.archive.org/web/20101029033020/http://simula.no/research/se/publications/Arisholm.2006.2/simula_pdf_file">"Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise"</a>. IEEE Transactions on Software Engineering. 33 (2): 65–86. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FTSE.2007.17">10.1109/TSE.2007.17</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:9889035">9889035</a>. Archived from <a rel="nofollow" class="external text" href="http://simula.no/research/se/publications/Arisholm.2006.2/simula_pdf_file">the original</a> on 2010-10-29. Retrieved 2008-07-21.</cite>

</li>

<li id="cite_note-9"><a href="#cite_ref-9">^</a> <cite id="CITEREFStephensDoug_Rosenberg" class="citation web cs1">Stephens, Matt; Doug Rosenberg. <a rel="nofollow" class="external text" href="http://www.methodsandtools.com/archive/archive.php?id=10">"Will Pair Programming Really Improve Your Project?"</a>. Retrieved 28 May 2011.</cite>

</li>

<li id="cite_note-10"><a href="#cite_ref-10">^</a> <cite id="CITEREFSarkarGordonNegreanuPoelitz2022" class="citation journal cs1">Sarkar, Advait; Gordon, Andrew D.; Negreanu, Carina; Poelitz, Christian; Ragavan, Sruti S.; Zorn, Ben (2022). <a rel="nofollow" class="external text" href="https://www.ppig.org/papers/2022-ppig-33rd-sarkar/">"What is it like to program with artificial intelligence?"</a>. Psychology of Programming Interest Group. Retrieved 27 March 2023.</cite>

</li>

<li id="cite_note-11"><a href="#cite_ref-11">^</a> <cite id="CITEREFWilliams,_L.Kessler,_R.2003" class="citation book cs1"><a href="Laurie_Williams_(software_engineer)" title="Laurie Williams (software engineer)">Williams, L.</a> & Kessler, R. (2003). <a rel="nofollow" class="external text" href="https://books.google.com/books?id=LRQhdlrKNE8C">Pair Programming Illuminated</a>. Boston: Addison-Wesley Professional. <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>9780201745764</bdi>.</cite>

</li>

<li id="cite_note-12"><a href="#cite_ref-12">^</a> <cite id="CITEREFFlor2006" class="citation journal cs1">Flor, Nick V. (2006). "Globally distributed software development and pair programming". Communications of the ACM. 49 (10): 57–8. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1145%2F1164394.1164421">10.1145/1164394.1164421</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:8963421">8963421</a>.</cite>

</li>

<li id="cite_note-jucs-13"><a href="#cite_ref-jucs_13-0">^</a> <cite id="CITEREFSchümmerStephan_Lukosch2009" class="citation journal cs1">Schümmer, Till; Stephan Lukosch (September 2009). <a rel="nofollow" class="external text" href="http://www.jucs.org/jucs_15_16/understanding_tools_and_practices/jucs_15_16_3101_3125_schuemmer.pdf">"Understanding Tools and Practices for Distributed Pair Programming"</a> (PDF). <a href="Journal_of_Universal_Computer_Science" title="Journal of Universal Computer Science">Journal of Universal Computer Science</a>. 15 (16): 3101–3125. Retrieved 2010-04-30.</cite>

</li>

<li id="cite_note-14"><a href="#cite_ref-14">^</a> <a rel="nofollow" class="external text" href="http://blogs.pathf.com/agileajax/2007/09/pair-programmin.html">Agile Ajax: Pair Programming with VNC</a> <a rel="nofollow" class="external text" href="https://web.archive.org/web/20080402003711/http://blogs.pathf.com/agileajax/2007/09/pair-programmin.html">Archived</a> 2008-04-02 at the <a href="Wayback_Machine" title="Wayback Machine">Wayback Machine</a>

</li>

<li id="cite_note-15"><a href="#cite_ref-15">^</a> <a rel="nofollow" class="external text" href="http://weblogs.asp.net/jcogley/archive/2004/10/13/242117.aspx">Pair Programming – The Ultimate Setup and the other options we tried. – Jonathan Cogley's Blog</a>

</li>

</ol></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><a rel="nofollow" class="external text" href="https://www.wikihow.com/Pair-Program">wikiHow: How to Pair Program </a> How-to guide; contains common wisdom on how to make pair programming work.</li>

<li><a rel="nofollow" class="external text" href="https://tuple.app/pair-programming-guide">Tuple:Pair Programming Guide</a> Pair programming guide that covers paring styles, antipatterns, and more. Includes example paring videos.</li>

<li><a href="https://wiki.c2.com/?PairProgramming" class="extiw external" title="c2:PairProgramming">c2:PairProgramming</a></li>

<li><a href="https://wiki.c2.com/?PairProgrammingPattern" class="extiw external" title="c2:PairProgrammingPattern">c2:PairProgrammingPattern</a></li>

<li><a href="https://wiki.c2.com/?PairRotationFrequency" class="extiw external" title="c2:PairRotationFrequency">c2:PairRotationFrequency</a></li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-30" href="https://en.wikipedia.org/wiki/?title=Pair_programming&oldid=1303408990">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>